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Abstract 

00 ' 

■ Ensuring compliance of organizations to federal regulations is a growing concern. This paper presents a framework 
I and methods to verify whether an implemented low-level security policy is compliant to a high-level security policy. 

CS| ■ Our compliance checking framework is based on organizational and security metadata to support refinement of 

high-level concepts to implementation specific instances. Our work uses the results of refinement calculus to express 
(]J • valid refinement patterns and their properties. Intuitively, a low-level security policy is compliant to a high-level 

I security policy if there is a valid refinement path from the high-level security policy to the low-level security policy. 

■ Our model is capable of detecting violations of security policies, failures to meet obligations, and capability and 
Cf^ I modal conflicts. 

p/j I Index Terms 

■ Policy refinement, action refinement, compliance checking, security policies, obligation, access control 

O , 

' — I. Introduction 

^ f J ECENT regulations, like Sarbanes-Oxley (SOX) [1] and Health Insurance Portability and Account- 
1%. ability Act (HIPAA) [2], are having a broad impact in information technology (IT) operations at 
\0 many organizations. For example, SOX requires organizations to place adequate internal controls over 
^ I financial reporting. HIPAA requires sufficient safeguards to be placed for controlling access to medical 
• ■ records. Moreover, these regulations require evaluations of safeguards and controls implemented by the 
^ organizations to determine whether they are compliant with the requirements. 

OO Tools to support automated compliance checking and establish formal properties are needed. Clearly, 
this is a complex problem requiring knowledge not only about the high- and low-level policies but 
also the available technologies, organizational requirements and processes, and system dynamics. Several 
^ policy languages [3]-[6] have been proposed by researchers. However, they were not designed to allow 
comparison of high-level and low-level security policies. 

In this paper, we focus on the specific problem of checking compliance of an implemented security 
policy to the high-level security policy of an organization. A high-level security policy may specify 
1) description of security requirements over abstract concepts, and 2) obligations, dispensations, and 
permissions. The low-level security policy gives specific security requirements over instances of abstract 
concepts. For example, let us consider an organization with a business process called Order Management. 
A rule in high-level policy may be that the Business Manager must protect the Order Management 
process from unauthorized access. Rules in low-level security policy may specify access control list for 
the purchase orders database used by the Order Management process. 

Refinement of a high-level policy into a low-level policy may require instantiation of roles, refinement 
of actions, and inference procedures. Many researchers have also proposed mechanisms for policy refine- 
ment [7]-[9], i.e. to derive the low-level enforceable policies from the high-level policies. Instantiation 
of roles has been studied extensively in context of access control [10]. The work of Backes et al. [11] 
focuses on comparing two privacy policies. However, the problem of verifying compliance of a low- 
level implemented policy to a high-level policy is not fully considered yet. In this paper, we propose a 
mechanism based on refinement calculus [12] to fill this gap. 
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In this work, we propose a policy refinement framework and action algebra that we apply for checking 
compliance of security policies. The proposed action algebra forms the basis of action refinements. To 
illustrate the need of action refinement to study compliance checking we now present an example. Let ai, 
a2, and 03 be actions, s a subject, and an object. Assume that allowing action ai is equivalent to allowing 
action 02 and disallowing action 03. If a high-level policy contains an access control rule (s, o, +ai) and 
low-level policy contains access control rules (s, o, +02) and (s, o, +03) then the low level policy is not 
compliant to the high-level policy. Intuitively, the policy compliance problem asks the question whether 
the low-level policy satisfies the relevant requirements of the high-level security policy. 

Our main contributions in this paper are development of an action algebra, a framework for policy 
refinement using refinement pattern, and a definition of compliance based on the concept of model 
checking. We describe a policy language that can model both high-level and low-level security policies. 
The proposed policy language is an extension of the Authorization Specification Language (ASL) and 
Flexible Authorization Framework(FAF) [5]. The extended language supports specification of obligations, 
dispensations, and authorizations. We have applied the principles of refinement calculus to security policies, 
and developed an action algebra that can be used to evaluate the correctness of action compositions. In 
addition, we have developed a policy refinement mechanism that combines action algebra and the policy 
language to refine high-level security policy into low-level security policies. Security policies are refined 
using action refinement patterns and derivation rules. The refinement process results in a set of possible 
low-level policies and corresponding system states. If the implemented low-level policy and the current 
system state corresponds to a derived low-level policy and state then we consider the implemented policy 
to be compliant to the high-level policy. 

Rest of the paper is organized as follows: Section HI] presents an overview of the proposed compliance 
checking framework. Section [III] presents definitions of basic constructs. Section |IV] describes action 
composition. Section |V] and |Vl] describe our extension of Flexible Authorization Framework(FAF) and 
the compliance checking process respectively. In Section IVIII we conclude and recommend future work. 

II. Compliance Checking Framework 

We propose a compliance-checking framework, where all entities in the concerned organization are de- 
scribed with ontological concepts. We define an ontology that models concepts like, subjects, permissions, 
obligations, actions, protection objects, and metadata associated with them and with the organization. Our 
compliance checking framework comprises of the following components: 1. an ontology, 2. instances of 
ontology concepts (e.g., users, organization's resources, roles, etc.), 3. a high-level security policy, 4. a 
set of low-level security policies, 5. refinement patterns, and 6. compliance checking engine. An overview 
of the compliance checking framework is shown in Figure [Ha). We now describe the components of the 
proposed compliance checking framework. 

We model security policies as locally stratified logic programs similar to Authorization Specification 
Language [5]. The security policy language presented in this work can represent obligation, dispensations, 
and authorizations. It also supports conflict resolution rules and policy refinement. Action refinement 
patterns specify refinement of an action of type A into a composition expression (Section HVT ) formed 
with sub-actions of A such that the constraints for satisfying any obligation of type A are preserved. 

The compliance checking engine in our framework refines the high-level security policy by recursively 
applying policy refinement rules. The refinement process continues until no new facts can be derived. The 
refined policies generated by this process comprise of ground rules and system-state information (facts) 
only. The set of all decision rules in a policy is called a decision view. 

The low-level security policy and system information given as input to check for compliance is now 
compared with the set of refined security policies generated. If the given system state satisfies post 
conditions of applicable obligations and the decision view of input low-level policy implies one of 
the possible decision views of high-level policy, we say that the given system complies to high-level 
policy. However, if the given system is not compliant, the compliance checking engine may also detect 
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violations of high-level policy and capability conflicts that prevent users from performing their obligations. 
In Section |VIl we discuss different types of violations and capability conflicts in further detail. 

Rules in high-level policy contain composite actions. Composite action consists of two or more sub- 
actions. We present an action composition algebra and Ontology based system model to check whether 
the action compositions are well-formed. 

In next section, we define constructs used to model system state and policy components like actions. 

III. Definitions 

This work uses ontologies to model the entities of our compliance checking framework. Our method 
relies on this ontology to aid the compliance checking as described in following sections. We now present 
our definition on Ontology used in this work. 

Definition 3.1: (Ontology) 
An ontology O is a 6-tuple (C, V, Ch, Vh, dom, range), where C is a set of classes, V is a set of properties, 
Ch is the subclass hierarchy of C and Vh is the subproperty hierarchy of V. dom and range are functions 
defined as dom : V P{C) and range : V P{C), where P{C) represents the power set of C. Let 
c G C be a class such that c G dom(pi) for i = 1, . . . , k and let rj represent the range{pi) for z = 1, . . . , A;. 
We represent the class c as c((pi, ri), . . . , (p^, r^)). 

Example 3.1: Let Computer be a class with properties os, owner, and name. Let the range of 
property os be given by the class OS, the range of property owner be given by the class Agent, and 
the range of property name be given by the class String. The class Computer is represented as 
Computer ( (os, {OS}) , (owner, {Agent}) , (name, {String}) ) . 

Figure [Hb) shows class hierarchy of the concepts used in our framework. Our ontology is an extension 
of the SUMO ontology [13] being developed by the IEEE SUO Working Group. The root node of our 
ontology is the class Entity. The class Entity refers to the fundamental concept in the domain being 
modeled. The class Object refers to physical objects. Binary relations that evaluates to true or false are 
represented by class Predicate. Process is a class of active components that occur and have temporal 
parts or stages. The class Agent represents something or someone that can act on its own. For example, 
software agents and human users. Human agents are represented by the class Users. A set of users is 
called a Group. A social position that is usually associated with some obligations and permissions is 
called a Role. The class Action represents a set of operations that the users may perform. Properties of 
the class Action are shown in Table IB 

Definition 3.2: (Object) 

Let O be an ontology. An object is an instance of any class c defined in O. Let c((pi, ri ),..., (p^, ^k)) 
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Property 


Range 


Semantics 


agent 


Agent 


Agent that actively carries out the process 


instrument 


Object 


Instrument is used by the process and is not modified 


resource 


Object 


Resource is modified and used by the process 


target 


Entity 


The entity acted upon or modified by the process 


evidence 


Predicate 


Predicate is true after the action is performed. 


subAction 


Action 


A distinguished part of the process 


causes 


Process 


This process causes or triggers another process of type 






specified by this property 


prevents 


Process 


Processes of type specified by this property are prevented 






by this process 



TABLE I 

OWL PROPERTIES OF CLASS ACTION 



be the definition of class c where pi, . . . ,pk are. properties of class c. We describe object o as o{(type, c), 
{pi, vi), . . . , {pi, vi)), where o is a unique identifier, and for each p7 there is a pj of c such that pi = pj 
and Vi is in range Vj. We use the notation Pi{o, Vi) to represent the i^^ property of o and its value. Note 
that type is one of the properites of o. 

Example 3.2: An object of type Computer with os SolarisS, owner Alice, and name Hadar is 
represented as Compl ( (type. Computer) , (os, SolarisS) , (owner, Alice) , (name, Hadar) ) , 
where Compl is an identifier used to represent the computer object in question. Also note that SolarisS, 
Alice, and Hadar are identifiers of other objects. 

Definition 3.3: (Data System) 
The Data System DS = {oi, . . . , o„} is a set of objects. 

Definition 3.4: (State) 

The state of a data system DS is described by properties of objects in DS, that is {pJ(oi, wi), . . . , 

pliCVk)} U...U {pUOn, <),... ,Pl{On, <)}. 

For simplicity, in the rest of this paper, we represent pi{oj,Vi) as Xi = Vi, where Xi is a variable 
representing the property pi of object oj. We say that the range of Xj is the same as the range of Pi. Let 
X = (xi, . . . , Xj, . . . , Xh) be the set of variables that describe a state in DS. The mapping from X to 
objects and their properties is maintained separately. 

Alternatively, a state 7 is defined as an assignment xi := vi, . . . , Xh '■= Vh, where Vi {i = 1, . . . , h) is 
value of variable Xj and Vi E ri. 

Note that a system may satisfy more than one state representations. These state representations are 
related to each other by refinement relation as we describe below. 

Definition 3.5: (State Refinement) 
Let 7 = {xi := vi, . . . ,Xn ■= I'n} and 7' = {xi := v[, . . . , Xn ■= v!^} be two states. We say that 7' is a 
refinement of 7 (7 C 7') if v[ <h vi, . . . ^v'^^ <h f„. Note that the refinement relation (□) between states 
is reflexive, transitive, and antisymmetric. 

Example 3.3: Let 7 = {xi:=Computer, X2:=Linux}, 7'= {xi:=Notebook, X2:=Linux} be two 
state representations for an object. Given, Notebook <^ Computer, we can say that state 7 is refined 
by state 7' (7^7'). 

Definition 3.6: (State Space) 
A state space is a set of states. 

Example 3.4: Let 71 = {xi:=Computer, X2:=Linux}, 72 = {xi:=Computer, X2:=Windows} be two 
states. Then the set F ={71,72} represents a state space. 

Description of a state space as illustrated in above example can be very tedious for large systems. In 
many cases, we want to specify only the variables of interest. We allow a more concise description of a 
state space in such cases as described below. 
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Let DS be a data system that can be described by variables Xi, . . . where range{xi) = ri {i = 
1, . . . , n). A state space V described as (xi = -yi, . . . , = Vk) {k < n) represents the following set of 
states: 

{xi := vi] X {2:2 := ^^2} X . . . {xk ■= Vk] x {xk+i := -y^+i, Xk+i ■= t^^+i, • • • , Xk+i := t^^J x . . . x {x„ := 
vl, Xn ■.= vl,..., Xn := v^} whcrc, range{xk+i) = {v^+i, . . . , <+J, . . . , range{xn) = {v},, ...,vl}. 

Example 3.5: Let us assume data system DS contains only two variables Xi and X2- Let state space V 
be described as (xi:=Computer), and ran5fe(a;2)={Linux, Windows}. 
Then V = {a:i:=Computer} x {a;2:=Linux, X2:=Windows}, 
i.e., r = { {a;i:=Computer, a:2:=Linux }, {xi:=Computer, X2:=Windows} } 

Intuitively, refinement of a state space means reaching a more specific state space. A more specific 
state space has fewer states or contains states that are sub states of states in other state space. Refinement 
of state space is now formally defined. 

Definition 3.7: (State Space Refinement) 
Let r and V be two state spaces. We say that V is refined by V (F □ V), if and only if V7' G V , 37 G T 
such that 7^7'. 

Example 3.6: Let us assume 71 = {xi:=Computer, a;2:=Linux}, 72 = {xi:=Computer, X2:=Windows}, 
and 73 = {a:i:=Notebook, X2:=Linux} are states, and Fi = {71}, r2 = {71,72}, and Fa = {73} describe 
state spaces. From definition of state space refinement, we observe 1) F2 is refined by Fi (F2 ^ Fi), as 
7i e Fi, 7i e F2, and 71 C 71 and 2) Fi is refined by F3 (Fi □ F3), as 73 e F3, 71 e Fi and 71 C 73. 

The refinement relation between states spaces is reflexive, transitive, and antisymmetric. 

F C F (reflexive) 

F C F' & F' □ F" ^ F C F" (transitive) 
F □ F' & F' □ F ^ F = F' (antisymmetric) 

Let S represent a non empty state space that contains all possible states of data system DS, and F(S) 
be the power set of S. The pair (P(S), C) is then a partially ordered set. Let F and F' be two elements 
(state spaces) in -P(S). The greatest lower bound of F and F' is given as F □ F' = F fl F'. The least upper 
bound of F and F' is given as F U F' = F U F'. 

Definition 3.8: (Restricted Subclass) 
Let c((jOi, ri), . . . , r„)) be a class. Then c{{p\, r[), . . . , (p*, r^)) is a restricted subclass, where at least 
one of r^, . . ., is a subclass or an instance of ri, . . . , r/,. respectively. For all other r[, r[ = r^. 

Example 3.7: Consider the class Computer defined in Example 13.11 The restricted class Computer 
( ( OS, Windows) ) represents the sub class comprising of all computers with operating system of type 
Windows. 

Definition 3.9: (Action) 

Let A and F be two state spaces. An action class A : A ^ F is a state transformer from A to F. An 
action a : (5 ^ 7 is an instance of action class A only if 6 E A and 7 G F. We call A as the initial state 
space and F as the final state space for action class A. 

In the rest of this paper, for each variable A, of type action class, we assume there exists corresponding 
initial and final state spaces and we use symbols Aj and Fj to denote them. 

Definition 3.10: (Monotonicity of Refinement) 
Let a : A ^ F be an action. Let {6} and {5'} be state spaces such that A □ {6} C {S'}. If a{d) 7 
and a{5') 7', then 7 □ 7'. 

Let a : A ^ F be an action. Let A' = {6[, . . . ,6'^} be a state space that refines A (A C A'). Let 
a{6l) 7- represent actions performed on states in the state space A', and let F' = {7J, . . . , 7^} be the 
state space after action a is performed. By definition of A, the state space F is refined by 7^' (z = 1, . . . , n). 
This implies that F □ F'. 

For better readability we often write F □ 7 instead of F □ {7} in rest of the paper. 

Actions are often composed of several other sub-actions. Composition may be performed by following 
operations: sequence (;), choice (V), and conjunction (A). These operators give us the following language 
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for expressing action composition: 

A:= a \ (A) \ Ai, ^2 Mi V ^2 Mi A A2 
where a is an atomic action, and Ai and A2 are subactions of A. The precedence order of the operators 
in action composition is () > A >; > V. We now describe properties of these operators. 

The choice operator (V) is a binary operator. If ai and 02 represent two action terms then ai V 02 
represents an action a that executes either oi or 02. The choice operation is commutative and associative. 

ai V ai = oi (ai V 02) V 02 = ai V (02 V 03) 

ai V 02 = 02 V ai 

The sequence operator (;) is also a binary operator. If ai and 02 represent two action terms then ai, a2 
represents an action that performs oi followed by 02- The sequence operator is not commutative. It is 
associative and is distributive over the choice operator. 

ai; {} = {}; «i = (f^i V 02); 03 = ai; as V 02; 03 

ai; a2 ^ 02; ai 03; (ai V 02) = 03; Oi V 03; 02 

(ai; 02); 03 = ai; (02; 03) 

Choice and sequence operators are the basic operators in our action algebra. The conjunction operator 
is a composite operator. If ai and 02 are two action terms, then a conjunction operation on ai and 02 is 
defined by ai A 02 = a^, 02 V a2] ai. Conjunction operator is associative, commutative and is distributive 
over the choice operator. 

ai A 02 = 02 A ai (ai A a2) A 03 = ai A (02 A 03) 

ai A (ai V 02) = ai A 02 V ai A 03 

Definition 3.11: (Action Refinement) 
Let a : A ^ r, oi : Ai ^ Fi and 02 : A2 ^ r2 be actions, and ai © 02 be an action composition. We 
say that Oi © 02 is a refinement of a, i.e., a C ai © 02, iff given any states 6 E A and 7 G F, where 
a{d) — > 7, the action composition (ai © 02) (f^) l', such that 7 □ 7'. 

We assume that the action composition ai © 02 used as a pattern to refine an action a in our model 
is alway more restrictive then a. Therefore, it not possible for the refinement process to derive a when 
further refining the composition ai © 02- 

Definition 3.12: (Atomic Action) 
An action a is an atomic action if it cannot be refined by any other action. 

Definition 3.13: (Action Tree) 
An action composition tree is a node-labeled binary tree where each internal node is labeled with an 
action and an operator pair, and each leaf node is labeled with an atomic action. The composition of 
actions represented by the child nodes is a refinement of the action at the parent node. 

In next section, we present types of action compositions that are allowed in this work. To provide 
assurance about correct compliance checking and policy refinement, action compositions must be well- 
formed. The concept of well-formed action composition is also discussed in next section. 

IV. Action Composition 

We first define types of action compositions categorized based on the depth of action tree. 

Definition 4.1: (Simple Composition) 
Let tti and 02 be two atomic actions and © be an action composition operator. An action composition of 
the form oi © 02 is called a simple composition. 

Definition 4.2: (Complex Composition) 
Let oi and 02 be two actions and © be an action composition operator. An action composition oi © 02 
is a complex composition if 1.) ai and 02 are either atomic actions, simple compositions, or complex 
compositions, and 2.) at least one of ai and 02 is not an atomic action. 

An action refinement pattern is a template for refining actions of a particular type. 
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Basic 


Advanced 


Sequence 


a C oi; 02 


o C oi; [A']o2 


Strict 


a C oi As 02 

O C Ol Vs 02 


a C oi As [A']a2 


Flexible 


O C Oi A 02 
O C Oi V 02 


O C Oi A [A']02 



Fig. 2 
Composition Types 



Definition 4.3: (Action Refinement Pattern) 
A refinement pattern 1ZV{A) is an action tree with root node of action type {A). 

We define additional types of composition in the context of refinement. We categorize action composi- 
tions as basic or advanced based on absence or presence of constraints in addition to operator type. Note 
that the advanced composition type is applicable only when it is required to perform both sub-action. 
Hence, it is not applicable to choice operations. 

Definition 4.4: (Basic Composition) 
Let a\ and be two actions. We say that a □ ai ©a2 is a basic composition if © is one of the operators: 
sequence, choice, or conjunction as defined in Section [III] and there are no additional constraints. 

Definition 4.5: (Advanced Composition) 
Let ai and 02 be two actions, © be an operator, and A' be a state space such that A2 ^ A' (or Ai □ A'). 
We say that a C ai © [A'] 02 (or a C [A']ai © 02) is an advanced composition if for all states in A' the 
sub action a2 (or ai respectively) can be ignored but for all states in A — A' both oi and 02 must be 
performed. 

We also categorize action compositions as strict or flexible based on the feasibility to perform both 
sub-actions in the initial state space or the feasibility to perform at least one of sub-actions in the initial 
state space. Strict and flexible action composition types are not applicable for sequence operators as the 
order of sub-actions is predetermined. 

Definition 4.6: (Strict Composition) 
Let a C ai©sa2, where ©^ represents a composition operator. We say that ai(Bs(i2 is a strict composition 
if A is constrained strictly to satisfy conditions such that both oi and 02 can be performed in the initial 
state for aU 5 G A. In other words, Ai Fl A2 ^ A. 

Definition 4.7: (Flexible Composition) 
Let a □ ai ©a2, where © represents a composition operator. We say that ai ©02 is a flexible composition 
if for all (5 G A, it is feasible to perform either ai or 02 in the initial state, and both ai and 02 must be 
performed, i.e., Ai U A2 ^ A. 

The above composition types may be combined. Figure |2] illustrates possible combinations. Constraints 
for correct action refinements for various composition types are given in Table UIl 

Definition 4.8: (Valid Action Trace) 
Action trace is an action composition where the composition is expressed using only the sequence operator. 
Given an action tree and an action trace, the trace is valid with respect to the action tree iff the trace can 
be derived from the root of the action tree using the properties of the operators. 

Definition 4.9: (Well-formed Action Composition) 
Let a □ ai © a2 be an action composition and let Ti, . . . ,T„ represent all the valid traces of the action 
composition. We say that an action composition is well-formed if and only if for each trace Tj, Ti{5) 7 
such that r □ 7, where A □ 5. 

Theorem 4.1: Basic Composition a C ai, 02 is well-formed if A C Ai, A2 ^ Fi, and F □ F2. 
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Composition Type 




Basic 


Constraints 


a C ai; a2 


Ai c A 


A2 g Fi F g F2 


Basic and Strict 


Constraints 


a C ai Vs 02 
a C ai As a'z 


Let (5 G A be the start state. 

Ai n Aa E A r C Pi F C Fa 
Ai C A A2 E A 
FCai(a2(5)) rEa2(ai(5)) 


Basic and Flexible 


Constraints 


a C ai V 02 
a C ai A 02 


Ai u A2 E A 
Ai u A2 E A 


AinA/{} A2nA/{} 
F g Fi F g F2 
Ai g (5 ^ A2 g ai(5) and F g a2(ai((5)) 
A2 g (5 => Ai g 02(5) and F g ai(a2(<5)) 


Advanced 


Constraints 


a C ai; [A']a2 


Ai E A 


A' g ai(5) ^ F g ai((5) 
A' g ai(5) ^ F g a2(ai((5)) 


Advanced and Strict 


Constraints 


a C ai As [A']a2 


AiEA AnA'/{} An A' g 5 ^ r E fliW 
A n A' E <5 ^ Ai E <5 and A' E a.i{5) and F E a2(ai(5)) 
A n A' E -5 ^ Ai E 02(8) and F E ai(a2(5)) 


Advanced and Flexible 


Constraints 


a C ai A [A']a2 


Ai U A' E A 

Ai E 5 and A' E cii(<5) ^ T E "2(01 ((5)) 

Ai E 5 and A' g 5 and A' g ai((5) ^ F g ai{5) 

A' E <5 and Ai g a2(<5) ^ F g ai(a2(5)) 



TABLE II 



Constraints for well-formed action refinement 



Proof. 

Initial State Trace Proof step 

A C 5 Ti = ai; 02 Ai □ A & A C (5 ^ Ai C 5 (by transitivity) (1) 

cii{5) — > 7i & Ti □ 7i (Definition of ai) 

A2 U Ti & Ti C 7i ^ A2 U 71 (by transitivity) (2) 

«2(7i) ^72 & U 72 (Definition of 02) 

r □ r2 & r2 U 72 ^ r □ 72 (by transitivity) (3) 

From (1), ai can be performed in the initial state. 

From (2), 02 can be performed after ai. 

From (1), (2) and (3), Ti is a valid action trace. 

Ti is a valid trace; therefore, a C ai; 02 is well-formed. □ 
Theorem 4.2: Basic and Strict Composition a U 02 is well-formed if Ai □ A2 U A, F □ Fi, and 

r CF2. 

Proof. 

Initial State Trace 

A C 5 Ti = ai 



T2 = 02 



Proof step 








Ai n A2 U A ^ Ai 


^ A 


(by set inclusion) 




Ai □ A & A □ (5 = 


^ Ai □ 5 


(by transitivity) 


(4) 


ai(5)^7i & TiC 


71 


(Definition of ai) 




F C Fi & Fi □ 7i 


=^rc7i 


(by transitivity) 


(5) 


Ai n A2 u A ^ A2 


^ A 


(by set inclusion) 




A2 C A & A C (5 = 


A2 C 5 


(by transitivity) 


(6) 


02(5) ^72 & F2 U 


72 


(Definition of 




FCF2 & F2C72 


=^FC72 


(by transitivity) 


(7) 
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From (4), ai can be performed in the initial state. 

From (4) and (5), Ti is a valid action trace. 

From (6), 02 can be performed in the initial state. 

From (6) and (7), T2 is a valid action trace. 

Ti and T2 are valid traces; therefore, a C ai 02 is well-formed. 
For all states in A, both ai and 02 can be performed. Hence, the constraints show that the composition 
is strict. □ 
Theorem 4.3: Basic and Strict Composition a C ai 02 is well-formed if Ai ^ A, A2 ^ A, 
r □ aiMS)) and T C 02(01(5)). 
Proof. 

Initial State Trace Proof steps 

A C (5 Ti = ai; aa Ai □ A & A □ 5 ^ Ai □ 5 (by transitivity) (8) 

rc 02(01(5)) (Hypothesis) (9) 

Ti = 02; ai A2 ^ A & A □ 5 ^ A2 ^ 5 (by transitivity) (10) 

rcai(a2(5)) (Hypothesis) (11) 

From (8), ai can be performed in the initial state. 

From (9), 02 can be performed after cii. 

From (8) and (9), Ti is a valid action trace. 

From (10), 02 can be performed in the initial state. 

From (11), ai can be performed after 02. 

From (10) and (11), T2 is a valid action trace. 

Ti and T2 are valid traces; therefore, a □ ai As 02 is a well-formed composition. □ 

Theorem 4.4: Basic and Flexible Composition a C aiVa2 is well-formed if A1UA2 ^ A, AiFlA ^ {}, 
A2 n A ^ {}, r C Ti, and T □ 12. 
Proof. 

Initial State Trace Proof steps 

A C (5 Ai U A2 ^ A & A □ 5 ^ Ai U A2 ^ 5 (by transitivity) (12) 

Ai n A ^ {} & A2 n A ^ {} (Hypothesis) (13) 

Ai □ 5 Ti = ai ai{6) ^71 & Ti □ 71 (Definition of ai) (14) 

A2 ^ 5 T2 = 02 02(71) ^72 & r2 ^ 72 (Definition of 02) (15) 

From (12), Initial state 6 is in either Ai, A2 or both. Therefore, at least one of ai and 02 can 
be performed. 

From (13), There are states in A which provide a choice between ai and 02. 
From (12) and (14), Ti is a valid trace. 
From (12) and (15), T2 is a valid trace. 

Ti and T2 are valid traces; therefore, a C Oi V 02 is well-formed. □ 

Theorem 4.5: Basic and Flexible Composition a C ai A 02 is well-formed if Ai U A2 ^ A, and for all 
5 e A if Ai C 5 then A2 C ai(5) and T □ a2(ai(5)), and if A2 C 5 then Ai □ a2{5) and T C ai(a2((5)). 
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Proof. 

Initial State 

A c 5 
Ai □ 5 

Ao C5 



Trace 



Ti = ai; 02 



02; Oi 



Proof steps 






Ai U A2 C A & 


A □ 5 ^ Ai U A2 ^ 5 (by transitivity) 


(16) 


A2 C ai(5) 


(Hypothesis) 


(17) 


rc 02(01(5)) 


(Hypothesis) 


(18) 


Ai ^ 02(5) 


(Hypothesis) 


(19) 


r c 01(02(5)) 


(Hypothesis) 


(20) 


in either Ai, A2 


or both. Therefore, at least one of Oi or 





From (16), Initial state 5 
02 can be performed. This constraint preserves the semantics of flexible composition. 
From (17), 02 can be performed after oi. 
From (17) and (18), Ti is a valid action trace. 
From (19), Oi can be performed after 02. 
From (19) and (20), T2 is a valid action trace. 

Ti and T2 are valid traces; therefore, o C oi A 02 is a well-formed composition. □ 

Theorem 4.6: Advanced Composition a C Oi; [A']a2 is well-formed under following conditions: 1) 
Ai C A, 2) if A' 2 oi(5) then V must be refined by ai(5), i.e.. A' ^ ai(5) ^ F □ oi(5), else performing 
action 02 after oi must lead to a state in F, i.e.. A' □ 0(5) ^ F C 02(01(5)). 

Proof. 

Initial State 

A □ 5 ^ Ai □ 5 
& FCoi(5) 
A C 5 ^ Ai □ 5 
& FC 02(01(5)) 



A □ 5 



Trace 

Ti = oi 



To 



Oi; 02 



(by transitivity) 
(Hypothesis) 
(by transitivity) 
(Hypothesis) 



(21) 
(22) 
(23) 
(24) 



Proof steps 

Ai □ A & 
A' g oi(5) 
Ai C A & 
A' □ oi(5) 

From (21), oi can be performed in initial state. 

From (21) and (22), Ti is a valid trace, when 02 can be ignored. 

From (23), Oi can be performed in initial state. 

From (23) and (24), T2 is a valid trace, when 02 can be performed after oi. 

Ti and T2 are valid traces; therefore, a C oi; [A']o2 is a well-formed composition. □ 

Theorem 4.7: Advanced and Strict Composition o C oi As [A'] 02 is well-formed if the following 
constraints are satisfied: 1) if Ai C A and A n A' g 5 then F C oi(5), 2) if A n A' C 5 then Ai C 5 
and A' □ oi(5) and F □ 03(01(5)), and 3) if A n A' □ 5 then Ai □ 02(5) and F □ 01(02(5)), and 4) 
An AV {} 
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Proof. 

Initial State 

A n A' g 5 



A n A' □ 5 T2 = ai; 02 



(by transitivity) (25) 

(Hypothesis) (26) 

(by transitivity) (27) 

(Hypothesis) (28) 

(Hypothesis) (29) 
(by set inclusion) (30) 

(by transitivity) (31) 



Trace Proof steps 

Ti = fli Ai C A & A □ 5 ^ Ai □ 5 
r □ ai{6) 

AiCA & AC5 ^ AiC(5 
A2 C ai(5) 
r C a2{a,{S)) 
T3 = 02; ai A n A' □ 5 ^ A' C 5 

A2 c A' & A' c 5 ^ A2 c 5 
Ai C 02(5) (Hypothesis) (32) 

rcai(a2((5)) (Hypothesis) (33) 

From (25), Oi can be performed in initial state. 
From (25) and (26), Ti is a valid trace. 
From (27), ai can be performed in initial state 
From (28), 02 can be performed after ai. 
From (27), (28), and (29), T2 is a valid trace. 
From (31), 02 can be performed in initial state. 
From (32), ai can be performed after 02 
From (31), (32), and (33), T3 is a valid trace. 

The constraint A □ A' 7^ {} ensures that the trace 02; fli exists. This preserves the semantics of a 
strict conjunction. 

Ti, T2, and T3 are valid traces; therefore, a ^ ai [A']a2 is a well-formed composition. □ 

Theorem 4.8: Advanced and Flexible Composition a □ ai A [A'] 02 is well-formed under following 
conditions: 1) Ai U A' □ A, 2) if Ai C (5 and A' □ ai{6) then T □ 02(01 ((5)), 3) if Ai C 5 and A' ^ S 
and A' g ai((5) then T □ ai((5), 4) if A' C (5 and Ai □ 02(5) then T □ ai(a2((5)). 
Proof. 

Initial State Trace Proof steps 

A C (5 AiUA' □ A & A □ 5 

AiC5 Ti = ai;a2 If A' C ai((5), 

A2 C A' & A' □ ai((5) ^ A2 C 
ai{d) 

r^a2{ai{6)) 
T2 = ai IfA'gai(5) 
r □ ai{5) 

A' □ 5 T3 = 02; ai A2 C A' & A' □ 5 ^ A2 C 5 

Ai □ a2{6) 
r C a^{a2{6)) 

From (34), Initial state 5 is in either Ai, A' or both. Therefore, at least one of Oi or 02 can 
be performed. 

From (35), 02 can be performed after oi. 

From (35) and (36), Ti is a valid trace. 

From (37), T2 is a valid trace. 

From (38), 02 can be performed in the initial state. 

From (39), ai can be performed after 02. 

From (38), (39) and (40), T3 is a valid trace. 

Ti, r2, and T3 are valid traces; therefore, a □ ai A [A'] 02 is a well-formed composition. □ 

Theorem 4.9: (Well-formed Complex Composition) 
Let ai : Ai ^ Fi and a : A ^ F be composite actions ai C 03 © 04 and a C ai © 02 respectively. An 
action composition a C (03 ©04) ©02 is a well-formed composition if the action compositions a □ ai©a2 



AiUA' □ (by transitivity) (34) 



(Case) 

(by transitivity) 

(Hypothesis) 
(Case) 

(Hypothesis) 
(by transitivity) 
(Hypothesis) 
(Hypothesis) 



(35) 

(36) 

(37) 
(38) 
(39) 
(40) 
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and «! □ 03 © 04 are well-formed. 

Proof. If tti is refined by the composition © a^, all traces of the 03 © must be valid. Also, it must 
be possible to perform 03 © 04 for all states in Ai. From Def. 13.1 1[ if ai □ 03 © a^, then for all 5 G Ai, 
— > 7i, such that, 

(as © a4)(^) 734 and 71 □ 734 (41) 
Similarly, for all 5 e A, a{6) 7, such that 

(ai © a2){6) 712 and 7 □ 712 (42) 
Let 034 = 03 ©04 be a state transforming function 034 : A34 Ts^. The action composition a C (ai ©a2) 
is well-formed if all traces of ai © 02 are valid even after substitution of ai with a34. We now prove 
validity of each possible trace. 



Case l:If ai, 02 is a valid trace then 034; 02 is a valid trace. 
If oi; 02 is a valid trace then 3 5 G A, such that Ai □ 5 

and ai(5) — 71, such that A2 ^ 7^ (43) 
and 02(71) — ^ 72. such that F □ 72 (44) 
From (41) and (43), we get, 

A2 ^ 7i ^ 734 or A2 ^ 734 (by transitivity) (45) 

Let 02(734) — *■ 7234, then from (44) and (45), we get, 

72 ^ 7234 (by monotonicity) (46) 

From (44) and (46), F □ 7234 (by transitivity). Hence, 034; 02 is a valid trace. 

Case 2: If 02; oi is a valid trace then 02; 034 is a valid trace. 
Reasoning is similar to Case 1. 



Case 3: If ai is a valid trace then 034 is a valid trace. 

If tti is a valid trace, 3 6 E A such that, ai{6) 71 and F □ 71 (47) 
From (41) and (47), F □ 734 (by transitivity). Hence 034 is a valid trace. 

Case 4: Refinement of ai does not effect the trace 02. □ 
Now we give an example of an action composition. 

Example 4.1: Let InstallFirewall, InstallAnt iVirus, and Protect be types of actions. 
Let a = Protect ( (target, $x) ) be a restricted subclass of class Protect, where $x is an object 
variable representing objects that satisfy the predicates type ( $x. Computer ) , and owner ($x, Alice) 
Composition of a may be described as follows: 

Protect ( (target, $x) ) □ InstallFirewall ( (target, $x) ) A 

[ $x ( (os , Windows ) ) ] InstallAnt iVirus ( (target , $x) ) 
This composition is an advanced composition using the conjunction operator. The sub-action Install- 
AntiVirus must be performed if the operating system is Windows. Otherwise the user may choose not 
to perform this action. 



V. Policy Specification Language 

In this section we briefly describe our approach to incorporate action refinement in authorization policies. 
For this we extend the Flexible Authorization Framework (FAF) [5] to express obligations, dispensations, 
and refinement. FAF is a logic-based framework to express authorization requirements. Access control 
permissions or denials are derived by a sequence of applications of the authorization rules. These sequence 
include the propagation, the conflict resolution, the decision, and the integrity modules. In addition, it 
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is ensured that every access request is either granted or denied, therefore ensuring completeness of the 
authorization policy. 

In our work, we provide extension of FAF, while preserving its properties with respect to complete- 
ness and decidability. Our extensions, that include predicates to express obligations, dispensations, and 
refinements in FAF will preserve the properties of locally stratified logic program. First, we give a brief 
overview of FAF. The FAF syntax is built from constants, variables, and predefined predicates. The 
constants and variables range over authorization objects, subjects, actions, and roles. FAF includes the 
following predicates: 

• cando{Xs ,Xo,Xa) 

• dercando{Xs, Xo, Xa) 
. do{Xs,Xo,X^) 

. done{Xs,Xo,Xa,Xt) 

• over AO and over as for overriding predicates 

• error for integrity violations 

• AOH and ASH for object and subject hierarhies 

For detailed explanation of these predicates, look at reference [5]. FAF rules are stratified by assigning 
levels to the predicates and requiring that the head predicate's level is equal or higher than the levels of 
the predicates in the rule body. Formal properties of FAF, such as unique stable model and well-founded 
model, as well as complexity analysis, are presented in [5]. 

In this work, we propose new predicates to express obligation and dispensation requirements. Table Hill 
shows the levels of these predicates along with the original FAF predicates. First, we start with the formal 
description of these concepts. 

Regulations often specify obligations as one of their requirements. In general, we interpret obligations 
as actions that users are required to perform to achieve specific goals. 

Definition 5.1: (Obligation) 
Let : A ^ r be an action type. An obligation o = obliges, A, q) is defined as a command to subject s 
to perform an action of type A, such that the condition q is satisfied. Definition of an obligation is said 
to be correct if F □ 7^ {}, where is state space representing all states in which q is true. Let 6 be 
the state of a given system. We say that subject s has satisfied obligation O if F □ C 7. If A ^ 5, 
the assumptions made to perform the action of type A are violated. Violating the assumptions releases 
the subject from the obligation. As this is not fault of the subject, it is considered to have satisfied the 
obligation. 

Definition 5.2: (Dispensation) 
Let A : A ^ r be an action type. A dispensation d = disp(s, A) is defined as an exemption given to 
subject s from performing an action of type A. 

Rules in our policy language consists of constants, variables, and predicates. They are defined as follows: 

1) Constant Symbols: Every member of Obj UTUUUGURUA, where Obj is the set of objects, 
T the set of types, U the set of users, G the set of groups, R the set of roles, A the set of action 
types. 

2) Variable Symbols: There are seven sets Vo, Vt , Vu, Vg , Vr , Va of variable symbols ranging over 
the sets Obj, T, U, G, R, A, respectively. 

3) Predicate Symbols: 

a) A 3-ary predicate symbol, hasObligation. The first argument is a subject term, the second 
argument is an action term, and the third argument is a boolean formula called post-condition. 

b) A 2-ary predicate symbol, hasDispensat ion. The first argument is a subject term, and the 
second argument is an action term. 

c) A 3-ary predicate symbol, derhasObligat ion, with the same arguments as hasObligation. 
The predicate derhasObligat ion represents obligations derived by using logical rules of 
inference (modus ponens plus rules for stratified negation [14]). 
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d) A 2-ary predicate symbol, derhasDispensat ion, with the same arguments as hasDis- 
pensation. The predicate derhasDispensat ion represents dispensations derived by using 
logical rules of inference (modus ponens plus rules for stratified negation). 

e) A 3-ary predicate symbol, mustdo, with the same arguments as hasObligat ion and 
derhasObligat ion. It definitely represents the actions that must be performed. Intuitively, 
mustdo enforces the conflict resolution and obligation policy. 

In addition, we allow use of cando, dercando, do, done, ovevASr ovevAOr error, hie— , 
and rel predicates as defined in FAR Table UlI] shows the strata of rules allowed in our policy to represent 
obligations, dispensations and their refinement. 



Level 


Stratum 


Predicate 


Rtiles defining predicate 





So 


hie-predicates 
rel-predicates 
done 


base relations 
base relations 
base relation 


1 


Si 


hasObligation 
hasDispensation 


body may contain done, hie- and rel- literals, 
body may contain done, hie- and rel- literals. 


2 


S2 


derhasDispensation 


body may contain hasObligation, hasDispensation, derhasDis- 
pensation, over, done, hie- and rel- literals. 


3 


S3 


derhasObligation 


body may contain hasObligation, hasDispensation, derhasObli- 
gation, derhasDispensation, over, done, hie- and rel- literals. 


4 


S4 


mustdo 


body may contain hasObligation, derhasObligation, hasDispen- 
sation, derhasDispensation, done, hie- and rel- literals. 


5 


Ss 


cando 


body may contain mustdo, done, hie- and rel- literals. 


6 


Se 


dercando 


body may contain mustdo, cando, dercando, done, hie- and rel- 
literals. 


7 


S7 


do 


in the case when head is of the form do(o,s,-l-a)body may 
contain cando, dercando, done, hie- and rel- literals. 


8 


Ss 


do 


in the case when head is of the form do(o,s,-a) body contains 
just one literal ^do(o,s,-l-a). 


9 


Sg 


error 


body may contain mustdo, hasObligation, derhas- Obliga- 
tion, hasDispensation, derhasDispensation, do, cando, dercando, 
done, hie- and rel- literals. 



TABLE III 

Obligation and Authorization Specification Strata 



Definition 5.3: (Obligation Rule) 
An obligation rule is a rule of the form: 

hasObligat ion ( s , a, q) ^ Li& . . . &L„ 

where s is a subject term, a is an obligation action type, g is a boolean formula composed with rel- 
predicates and done literals, and Li& . . are done, hie- or rel- literals. 

Example 5.1: Let us assume that an organization requires computers to have firewall software installed 
to be considered safe. The obligation "Employees must protect computers they own from unauthorized 
access" is then modelled by following obligation rule: 

hasObligation ($s. Protect ( (target, $x) ), haslnstalled ($x, $y) 
& type ( $y, Firewall ) ) «— type ( $x, Computer ) & type ($s, Employee) 
& owner ($x, $s) 

where Sx, $y, and $s are variables. Protect is a sub-class of Action, Computer and Employee 
are sub-classes of Object, type is a hie predicate, and target, haslnstalled, and owner are 
rel predicates. 

Let us assume that the data system contains two Employee objects and three Computer objects such 
that the following predicates hold in the system state: 

type (pel. Computer ), type (empl , Employee) 
type(pc2. Computer ), type (emp2 , Employee) 
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type(pc3, Computer ), owner (empl , pel) 
owner(emp2, pc2 ), owner (empl , pc3) 

When above obligation rule is evaluated in the data system presented above, the results of evaluations are 
( $x=pcl , $s=empl ) , ( $x=pc2 , $s=emp2 ) , and ($x=pc3, $s=empl ). Applying the evaluation 
results to the obligation rule creates following three obligations: 

hasObligat ion (empl , Protect ( (target , pel )) , haslnstalled (pel , $y) 

& type ( $y, Firewall ) ) 
hasObligat ion (emp2 , Protect ( (target , pc2 )) , haslnstalled (pc2 , $y) 

& type ( $y, Firewall ) ) 
hasObligat ion (empl , Protect ( (target , pc3 )) , haslnstalled (pc3, $y) 

& type ( $y, Firewall ) ) 

Definition 5.4: (Dispensation Rule) 
A dispensation rule is a rule of the form: 

hasDispensat ion ( s , a) ^ Li& . . . &L„ 

where s is a subject term, a is an obligation action type, and Li& . . . &L„ are done, hie- or rel- literals. 

New obligations and dispensation may be derived from existing obligations, dispensations, hie- and 
rel- predicates using inference rules called derivation rules. For example, a derivation rule can specify 
propagation of obligation via subject hierarchy, and delegation of duties. Definition of dispensation and 
obligation derivation rules follow. 

Definition 5.5: (Dispensation Derivation Rule) 
A dispensation derivation rule is a rule of the form: 
derhasDispensat ion ( s , a) ^ Li& . . . &L„ 

where s is a subject term, a is an obligation action type, and Li& . . . &L„ are hasDispensat ion, 
derhasDispensat ion, done, hie- or rel- literals. All derhasDispensat ion literals appearing 
in the body must be positive. 

Definition 5.6: (Obligation Derivation Rule) 
An obligation derivation rule is a rule of the form: 

derhasObligat ion ( s , a, q) <— Li & ... & L,„ 
where s and a are terms of ST and OA respectively, g is a system state, and Li & ... & L„ are 
hasObligat ion, derhasObligat ion, derhasDispensat ion, done, hie- or rel- literals. 
All derhasObligat ion literals appearing in the body must be positive. 

Definition 5.7: (Derivation View) 
A derivation view is a finite set of derivation rules. 



A. Policy Refinement 

We use derivation rules to refine a high-level policy into low-level policy. Derivation is based on subject 
hierarchy as in FAF, and action refinement patterns. A discussion of types of derivation rules is presented 
below. 

A. Derivation via subject-hierarchy 

Propagation of obligations and dispensation can be achieved via subject-hierarchy. Dispensation derivation 
rules expressing propagation via subject-hierarchy may have the following form: 

derhasObligat ion ( s , a, q) ^ hasObligat ion ( s ', a, q) & hie(s,s') 
derhasObligat ion ( s , a, q) <^ derhasObligat ion ( s ', a, q) & hie(s,s') 
derhasDispensat ion ( s , a) ^ hasDispensat ion ( s ', a) & hie(s,s') & 

derhasDispensat ion ( s , a) ^ derhasDispensat ion ( s ', a) & hie(s,s') 

where Li& . . . &L.„ are hasDispensation, derhasDispensat ion, done, hie- or rel- liter- 
als. All derhasDispensat ion literals appearing in the body must be positive. 
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Obligation derivation rules expressing propagation via subject-hierarchy may have the following form: 

derhasObligat ion ( s , a, q) ^ hasObligat ion ( s ' , a, q) & 

hie (s, s' ) & Li & . . .& L„ 
derhasObligat ion ( s , a, q) ^ derhasObligat ion ( s a, q) & 

hie (s, s' ) & Li & . . .& L„ 
where Li& ... &L„ are hasObligat ion, derhasObligat ion, derhasDispensat ion, done, 
hie- or re/- literals. All derhasObligat ion literals appearing in the body must be positive. 

Example 5.2: Let us assume that a security policy specifies that all employees have an obligation to 
protect computers they own. A manager is a type of an employee. Hence, managers have an obligation 
to protect computers they own. This derivation rule is represented as follows: 

derhasObligat ion ( $S2f Protect (target $x),q) <^ 
hasObligat ion ( $Si, Protect (target $x) , q) & 

isa (Manager, Employee) & type ( $Si, Employee) & type ( $S2, Manager ) & 
owns($Si,Nl) & type(Nl, Computer) 
B. Derivation via action refinement 

New obligation rules and dispensation rules may be derived from a high-level obligation or dispensation 
rule, by substituting the action in high-level rule with its sub-actions as specified in refinement pattern. 
We now discuss construction of derivation rules based on basic and strict action composition operators. 

Let hasObligat ion (s, a, q) ^ Li & ... & L„ be an obligation rule, and let ai : Ai — > Fi and 
a2 : A2 — > r2 be the sub-actions of a : A ^ F. Then the given obligation rule can be refined into 
obligation rules for sub-actions as described below. 

B.l Distribution over sequence operator 

Let a □ ai; a2 be the refinement pattern for action of type a. An obligation rule to perform action a can 
be refined into two obligations to perform sub-actions ai and 02 with rules of following form: 

derhasObligat ion ( s , ai, gi ) ^ Li & ... & 

derhasObligat ion ( s , 02, g) ^ done (ai) & hasObligat ion ( s , a, q) 

where gi = Fi fl A2. We constrain the post-condition of first obligation action ai to satisfy pre-conditions 
required to perform second obligation action a-z- 
B.2 Distribution over choice operator 

Let a C oi V 02 be the refinement pattern for action of type a. Let R be the rule that derives obligation 
to perform a. We know that if either ai or 02 is performed the obligation is satisfied. Therefore, an 
obligation rule to perform action a can be refined into either of the following two obligation rules _Ri and 
i?2- Application of this refinement pattern to a policy P generates two refined policies Fi and P2- The 
rule rule i? in P is substituted with Ri and i?2 to generate Pi and P2 respectively. 
Pi: derhasObligat ion ( s , ai, q) ^ Li & ... L Ln -idone (02) 
P2: derhasObligat ion ( s , 02, q) ^ Li & ... Sz Ln Sz -idone (ai) 

B.3 Distribution over conjunction operator 

When an action a is refined by an action composition of form ai A 02, we refine the policy in two steps. 
First, we substitute ai A 02 with the composition V 04, where □ ai; 02 and 04 C a2; ^i- This allows 
us to apply action refinement mechanism for choice operator as we described above. In second step, we 
refine actions 03 and 04 in resulting policies using the action refinement mechanism for sequence operator. 

B. Deriving Authorizations 

Security policies may also contain authorization rules in addition to obligation and dispensation rules. 
Moreover, the policy refinement mechanism presented in the previous section can be extended by adding 
rules that derive permissions and prohibitions from predicates defined in obligation specification strata. 
In this section, we examine authorization rules that may contain obligations and dispensations. 
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From the perspective of refining a security policy, an obligation to perform an action suggests that the 
subject must have permission to perform or execute the obligation action. 

Definition 5.8: (Authorization Rule) 
An authorization rule is a rule of the form: 

cando (o, s, <sign>a) ^Li&...&L„ 
where s is a subject term, a is a signed action type, sign is either + or -, and Li& . . . &L„ are must do, 
done, hie- or rel- literals. 

Example 5.3: Suppose an obligation decision rule is derived saying that subject s is required to encrypt 
an object x. To be able to fulfill the obligation s must have permission to execute Encrypt action or 
function. 

cando (Encrypt ( (target , x) ) , s, +execute) ^ 
mustdo(s, Encrypt ( (target , x) ) , q) 

Obligation to perform an action can also imply prohibition to perform certain actions. Prohibitions are 
represented by authorization rules specifying a - sign for the action. 

Example 5.4: Suppose subject s has an obligation to encrypt email messages that contain confidential 
messages. To ensure compliance to this policy rule, the policy-refinement procedure can add a rule 
disallowing s to send email if its contents are confidential. Such a rule may be expressed as follows: 
cando (sendEmail ( (message, x) ) , s, -execute) ^ 

mustdo(s. Encrypt ( (target , x) ), q) & type (x, EmailMessage) & 
messagetype (x, PlainText) & hasClassificat ion (x, Confidential ) 

To perform an obligation action, the subject s may need permissions on objects accessed by the 
obligation action. Objects that are accessed but not modified are described by instrument property 
of the class Action. Objects that are accessed and modified by an action are described by resource 
property of the class Action. An obligation to perform an action can be refined into authorization rules 
for instrument and resource objects as shown below: 

cando ($r, s, +modify) ^ mustdo ( s , a, q) & resource (a, $r) 
cando ($i, s, +read) ^ mustdo ( s , a, q) & instrument (a, $i) 

Authorization derivation in this framework have definition same as in FAF [5]. It is given below to 
provide complete description of this framework. 

Definition 5.9: (Authorization Derivation Rule) 
An authorization derivation rule is of the form: 

dercando (o, s, <sign>a) ^Li&...&L„ 
where o is an object term, s is a subject term, a is an action term, sign is either + or -, and Li, . . . , L„ 
are either cando, over, dercando, done, hie-, or rel literals. All dercando-literals appearing in the body of 
a derivation rule must be positive. 

Definition of authorization decision rules in our policy refinement framework is different than that in 
FAF. FAF uses a closed policy and creates a prohibition for all actions that are not explicitly permitted. 
However, in policy refinement we assume that the refinement of high-level policy may not generate all 
the positive authorization rules that may be present in the low-level security policy. We do require that 
all negative authorization rules generated by policy refinement must be present in the low-level security 
policy. We assume that the high-level policy does not contain positive authorization rules, and the low-level 
policy may not override positive authorizations derived from the high-level policy. 

Definition 5.10: (Authorization Decision Rule) 
An authorization decision rule is of the form: 

do (o, s, <sign>a) <^Li&...&L„ 
where o is an object term, s is a subject term, a is an action term, sign is either -i- or -, and Li, . . . , L„ 
are either cando, dercando, done, hie-, or rel literals. 
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C. Conflict Resolution 

Policy refinement must lead to decision whether a subject has an obligation to perform an action or 
not. However, policies may generate conflicting rules. For example, a subject may have an obligation to 
perform an action a and can also have a dispensation for action a at the same time. Conflict resolution 
rules are added to deal with such situations. 

A conflict resolution rule expressing that dispensations take precedence can be of following form: 
derhasDispensat ion ( s , a) ^ hasDispensat ion ( s , a) & 

hasObligat ion ( s , a, q) & Li&...&L„ 

Conflict resolution rules that express obligation takes precedence are expressed as obligation decision 
rules (Def. ISHl) 

Deflnition 5.11: (Obligation Decision Rule) 
An obligation decision rule is a rule of the form 

mustdo ( s , a, q) ^ Li & ... & L„ 
where s and a are elements of S and OA respectively, 5 is a system state, and Li & ... k. Ln 
are hasObligation, derhasObligat ion, hasDispensat ion, derhasDispensat ion, 
done, hie- or rel- literals and every variable that appears in any of the Lj's also appears in the head of 
this rule. 

Separation of duty requires that for a particular set of actions in a transaction, no single individual be 
allowed to execute all actions within the set. Separation of duty is often enforced with access control 
policies. In the policy refinement model presented in this work, positive authorizations are derived from 
obligations. A user must have permissions to perform actions he is obliged to do as discussed above. 
However, the derived permissions must reflect separation of duty requirements. Hence, the obligation and 
dispensation rules must be modeled to handle separation of duties. 

For example, if the separation of duties require that actions ai and 02 must not be performed by the 
same subject. A subject obliged to perform 02 must be given dispensation on action ai. In such cases, 
an additional obligation derivation rule can be stated to specify alternate subject that will be required to 
perform action ai and complete the transaction successfully. 
derhasDispensat ion ( s , ai) ^ derhasObligation (s, ai, gi) & 

derhasObligat ion ( s , a2, ^2) & i^i & ... k Ln 
derhasObligat ion ( s ', Oi, gi ) derhasDispensat ion ( s , ai) & L\ L'^ 
where s' is a subject term defined in body of the rule. 

In addition, a policy may have modal authorization conflicts, i.e., policy refinement may generate both 
positive and negative authorizations on same object for a subject. For example, policy refinement may 
derive positive authorizations for a subject on objects required to perform his/her obligations. However, 
there may be another rule in the policy prohibiting access to the required object. In this case, a conflict 
resolution rule may be defined to allow the subject to access required objects. In general, conflict resolution 
rules for authorizations are modeled as authorization decision rules (Def. 15.101) . 

Deflnition 5.12: (Decision View) 
A decision view is a finite set of decision rules. 

Deflnition 5.13: (Integrity Rule) 
An integrity rule is of the following form: 

error Li&; . . . &;L„ 

where Li, . . . , L„ are mustdo, hasObligation, derhasObligation, hasDispensation, derhasDispensation, do, 
cando, dercando, done, hie-, and rel- literals. 
Deflnition 5.14: (Policy) 

A policy P = {R, DS, E) is a set of rules R = HVJAVJM characterized by its scope DS and environment 
E, where if is a set of obligation rules and dispensation rules, A is a set of authorization rules, and M is 
a set of propagation rules, conflict resolution rules, and integrity rules. Scope specifies set of target objects 
to which the policy is applicable, and environment specifies compliance verification context information 
like date, time, location, subject, etc. 
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Example 5.5: Let us now consider an example illustrating application of derivation rules, and decision 
rules for policy refinement. Consider the following security policy: 

hasObligation ($s, Protect ( (target, $x) ) , true) <— 

type($s, Employee) & owns($s,$x) & type($x, Computer) 
hasDispensat ion ( $ s , InstallFirewall ( (target, $x) ) ) <— 

type($s. Employee) & owns($s,$x) & type ( $x, Computer ) & 

hasRole($s, Manager) 
mustdo($s, $a, $q) ^ derhasObligat ion ( $ s , $a, $q) & 

-1 derhasDispensation ($s, $a) 
Let the refinement for action Protect be defined by following action composition: 
Protect ( (target, $x) ) C InstallFirewall ( (target, $x) ) A 

InstallAnt iVirus ( (target, $x) ) 
Let the following predicates hold in system state: 
type (Alice, Employee), hasRole (Alice, Manager), 
owns (Alice, NBl), type(NBl, Computer) 

To refine the security policy, we first apply the derivation rules to derive all predicates in stratum OS2, 
followed by derivation of all predicates in stratum OS's, and so on. We first, evaluate the variables in 
obligation rules and dispensation rules using the system state. For above security policy, following rules 
are derived after evaluation: 

hasObligation (Alice, Protect ( (target, NBl)), true) <— 

type (Alice, Employee) & owns (Alice, NBl ) & type (NBl, Computer) 

hasDispensat ion (Alice, InstallFirewall ( (target, NBl))) ^ 

type (Alice, Employee) & owns (Alice, NBl ) & type (NBl , Computer ) 
& hasRole (Alice, Manager) 
We now apply derivation rules, e.g., derivation rules for policy refinement by action refinement. By 

refining action protect, we obtain following rules: 

derhasObligation (Alice, InstallFirewall ( (target, NBl)), true) ^ 

type (Alice, Employee) & owns (Alice, NBl ) & type (NBl, Computer) 
derhasObligation (Alice, InstallAntiVirus ( (target, NBl)), true) ^ 
type (Alice, Employee) & owns (Alice, NBl ) & type (NBl, Computer) 
No new predicates can be further derived in this level. Hence, we now apply the decision rules to 
obtain predicates in higher stratum. Since, both predicates derhasObligation (Alice, Install- 
Firewall ( (target, NBl)), true) and derhasDispensation (Alice, InstallFirewall 
( (target, NBl) ) ) hold, a mustdo predicate for Alice to perform the action InstallFirewall 
cannot be derived. However, a mustdo predicate for InstallAntiVirus action is derived from the 
following instance of decision rule: 

mustdo (Alice, InstallAntiVirus ( (target, NBl)), true) *— 

derhasObligation (Alice, InstallAntiVirus ( (target, NBl)), true) 
& -1 derhasDispensation (Alice, InstallAntiVirus ( (target, NBl))) 

VL Compliance 

To check compliance, we compare a high-level security policy with a low-level security policy in context 
of a data system. The set of do and mustdo ground predicates that can be derived from a security policy 
and a data system is called ground decision view. 

Definition 6.1: (Compliance) 
A low-level policy Pi is compliant to a higher-level policy Ph for a given DS, if there exists a {Ph, DS)ref, 
such that {Pi, DS) =^ {Ph, DS)ref, where DS is the data system, {Pi, DS) represents the ground decision 
view of low-level security policy, and {Ph, DS)ref represents the ground decision view of refined high-level 
security policy. We assume that Ph does not contain any positive authorization rules 
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Algorithm \T\ describes the steps needed to check compliance of a give low-level policy and system 
state to a given high-level policy. First, the algorithm decision view of low-level security policy. The 
low-level policy is a stratified logic program and can be evaluated in polynomial time [5]. We then refine 
the high-level policy. The refinement process can lead to multiple refinements of high-level policies due 
to action refinement over the choice choice operator (V) and conjunction operator (A). The process of 
refining low-level policies is analogous to a top-down tree traversal, where each internal node of the tree 
represents the refinement stage at which an action is refined into a composition with choice operator or 
conjunction operator. The leafs of the tree represent derivation of refined policies with atomic actions. 
Therefore, the complexity of the policy refinement can be seen as exponential in terms of height of this 
evaluation tree, which corresponds to number of time action refinement has to be applied to reach atomic 
actions. Finally, the algorithm checks for compliance by searching for a refinement of high-level policy 
such that all the access control and obligation requirements specified in the refined policy are satisfied by 
the low-level policy or current system state. 

A given refinement of high-level policy and low-level policy can also be compared to detect conflicts 
among them. We categorize conflicts between a (high-level) security policy and system state (low-level 
policy and object properties) into following four categories: 

Definition 6.2: (Modal Authorization Violations) 
A modal violation occurs when a high level policy has granted authorization but a low level policy denies 
authorization. 

Let Rh be a authorization decision rule do{s, o, —a) <— Li& . . . &L.„ in refinement of high level policy 



Algorithm 1: Compliance checking algorithm 

input : High-level security policy P/j, Low-level security policy P;, Data System DS, Refinement Patterns RP, Cunent State cr 
output: true if P; and cr are compliant to Pf^, otherwise false 

// Generate ground decision view of P; give a data system DS 
Evaluate the variables in P;. 

Instantiate the variables in P; to derive ground rules. 

Apply derivation rules and conflict resolution rales until no new fact is generated. 
Apply Integrity rules. If errors are found report that policy P; is inconsistent. 

// Generate all ground decision views of Pfi given a data system DS 
II Note that multiple decision views may be derived from Pjj. 
Evaluate the variables in P/j. 
repeat 

Instantiate the variables in P^j to derive ground rales. 

Apply derivation rales, and conflict resolution rules until no new fact is generated. 
Apply Integrity rules. If errors are found report that poHcy P;j is inconsistent, 
until no new fact is generated 

II Compare ground decision views, which consists of authorization obHgation decision views, 
compliant <— false 

foreach decision view derived from Py^ do 
found ^ true 

// Compare authorization decision views. 

Let Z);j be the set of do predicates derived from P^ and are applicable in DS and cuiTent state a. 
Let D; be the set of do predicates derived from P; and are applicable in DS and current state cr. 
if Dh 1 Di then 
L found ^ false 

// Compare obligation decision views 

Let Mft be the set of must do predicates derived from Pfi and are applicable in DS and current state cr. 
Let Ml be the set of mustdo predicates derived from P; and are applicable in DS and current state cr. 

(Note that P; may have no means to enforce obligations or P; may not contain obligations. In such cases, we consider M; to be empty and 
check for satisfaction of obligations in M^.) 
foreach predicate mustdo (s, a, q) in Mf^ do 

Let ea be the effect of action a asserted by ontology. 

Compute Ba by evaluating effect (a, Ca) given data system DS 

if not ((mustdo (s, a, q) in Mi) OR (a =^ q and cr => Ca)) then 
L found ^ false 

compliant <— compliant OR found 
if compliant then 
L break 

return compliant 
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Ph, and Ri be an authorization decision rule do(s,o,+a) ^ L[Sz . . . in low-level policy P/. and 
Ri have a modal conflict if Li& . . . &L„ and L[Sz . . . can be true simultaneously for any system state 
G. 

A modal authorization violation may be modeled with rules of following form: 
error ^ ((Pi,DS)^ do (s, o, +a) ) & {{Ph,DS)^ do (s, o, -a)) 
Definition 6.3: (Obligation Violations) 

An obligation violation occurs, when a subject either does not perform his or her obligations or does not 

perform obligations correctly. 

Let mustdo{s, a, q) ^ Li& . . . &L„ be an obligation decision rule, where s is a subject, a is an action, 
g is a post condition, and Li& . . . &L„ is a precondition. Let be an effect of action a asserted by the 
ontology. When Li& . . . &L„ holds but & is not satisfied, an obligation violation is indicated. 

We assume that prior to the time of compliance checking the subject had sufficient time to perform 
obligations satisfactorily. Detection of obligation violation may be modeled with rule of following form: 

error ^ Li& . . . &L„ & -iCa & ~ig 

Definition 6.4: (Resource Capability Conflict) 
Resource capability conflict occurs when resources required to perform an obligation does not exist. 

Let DS = {O, I) be a data system, where O is an ontology and / is set of objects in the system. A 
resource capability conflict may be modeled with rules of following form: 

error ^ mustdo ( s , a, q) & resource (a, r) & (r ^ I) 

Definition 6.5: (Modal Capability Conflict) 
Modal capability conflict occurs when an obligation requires access to certain resources, and the subject 
does not have the requisite permissions. 

error ^ mustdo ( s , a, q) & -ido (a, s, +execute) 

Theorem 6.1: Obligation and Authorization specification is a locally stratified logic program, thus 
preserves the desirable properties given in Theorem 1 of [5]. 

Proof Sketch: Authorization specification language has been extended by introducing new predicates. 
Table UlI] shows that all atoms in the specification can be assigned a rank such that no atom depends on 
an atom of greater rank or depends negatively on one on equal or greater rank in any instantiated rule. 
Proof of this theorem is similar to the proof of Theorem 1 of [5]. □ 

We assume that the high-level policy does not contain positive authorization rules. Any authorizations 
derived from Ph must be derived from obligation and derivation rules. If Dh ^ Di then low-level security 
policy is prohibiting some users from performing their obligations. This is a case of modal capability 
conflict and the algorithm correctly returns false. 

Obligations derived from the high-level security policy must occur in a compliant low-level policy or 
the obligations must have been satisfied. If the obligation is satisfied, the obligation postcondition must 
be true and the effect of obligation action must also be true. The compliance checking algorithm returns 
false, when both the above conditions are not satisfied. 

Theorem 6.2: Compliance checking algorithm (Alg. [T]) terminates and the algorithm returns false if 
low-level security policy and system state is not compliant with the high-level security policy. 
Proof Sketch: The compliance checking algorithm computes decision view of the high-level and low- 
level policy by evaluating their obligation and authorization specifications, which are locally stratified logic 
programs. The herbrand base of the obligation and authorization specification is finite. Also, the variables 
used in the rule head are bounded by the variables in the body of the rule. The policy refinement process 
performs substitution of rules in the high-level policy until actions can not be further refined. Action 
refinements in our framework cannot contain loops as the refinement are always more specific. Therefore 
the number of times action refinement may be performed is finite. We consider a finite DS, thus only a 
finite number of instantiations may occur; therefore Alg. \T\ terminates. 

If the low-level security policy violates the high-level security policy, the algorithm detects the violation 
and returns false. This is proved by contradiction. Let us assume that the low-level security policy Pi 
violates high-level security policy Ph and the compliance checking algorithm returns true. The algorithm 
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can return true only if I) C Di, and 2) for every mustdo(s,a,q) predicate in M^, either mustdo(s,a,q) 
is in Ml or (a ^ q and a =^ Ca). The decision views (Pi,DS) and {Ph, DS)ref contain only ground 
mustdo and do predicates. If {a ^ q and a =^ Ca), the obligation a has already been satisfied in Pi. 
As discussed the remainder of mustdo and do predicates also occur in (Ph, DS)ref- Hence, the low-level 
security policy is compliant to high-level security policy. This is in contradiction to initial assumption. □ 

VII. Conclusions 

In this paper we proposed a framework and techniques to evaluate whether a low-level, implemented 
security policy is compliant to a high-level policy. Our method uses organizational and security meta- 
data and a set of well-defined operations to generate valid refinements of a given high-level policy. The 
implemented policy is compared to these refinements to verify whether it is compliant to the high-level 
policy. The correctness of the compliance is based on the properties of the refinement, that is the well- 
formedness of the refinement operators and the validity of the compositions. 

Although the basic concept presented in this work have been proposed and used in other fields of 
research and development, e.g., software engineering and programming languages, their relevance for 
information security have not yet been fully evaluated. Our aim is to build upon these technologies to 
establish formal properties of security policies. This work constitutes our initial efforts on incorporating 
results from software refinement [15], [16], requirement analysis, and process algebra [17]-[23] in security 
policy verification. Our ongoing work includes analysis of more complex policy refinements, usage of 
extensive organizational meta-data, and bottom-up compliance verification. Our goal is to develop methods 
and tools that will aid and simplify the human evaluation process for compliance checking. 
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